The present invention relates to the field of software-based services in communication networks. More particularly, it includes systems and methods for maintaining and utilizing routing data to handle event notifications generated by call handling in a service logic execution environment.
A service is a software application that is installed in a communication network to provide value added functions to subscribers. Subscribers are users of the communication network who subscribe to the services. Services control the network to perform value-added functions for subscribers based on provisioned data and network conditions. Service instance is a single run time instance of the service that provides the service functions to a subscriber. A service may include one or more service instances, which may be operating in different modes to handle different phases of providing the service. Service Logic Execution Environment (SLEE) is the run time environment in which a service executes. A SLEE is a new approach to the long-standing issue of how to supplement switches with intelligent capabilities. Sun Microsystems, Inc. has sponsored development of telecommunications computing standards, so that service logic execution environments will have open, non-proprietary architectures. The so-called JAIN SLEE standard reached the stage of public comment on 12 Aug. 2002, having gone through drafts prior to that. A SLEE is intended to support multiple services and accept software written by multiple vendors in compliance with one or more telecommunications computing standards.
The JAIN SLEE standard leaves much to be filled in by the service developer. JAIN SLEE is essentially an application program interface (API) specification that does not specify the internal details of implementing services. JAIN SLEE specification is very generic in the definition of service and subscriber data. This provides a lot of flexibility but comes with a cost, as it places the burden on the service developers to provide the necessary Management interfaces. The standard does not provide any mechanism for the service developer to define the data schema for the service and subscriber data. Nor does it define any mechanism to provide sophisticated data provisioning and management. The complementary Java Management (JMX) standard is still evolving. In JAIN SLEE, Event Triggering is the primary mechanism to invoke services, which limits efficient use of the Services by other applications and clients that are not based on an event model, such as web based provisioning and statusing interfaces.
Traditionally, both before JAIN SLEE and even now, as the first public comment draft is being circulated, service execution platforms are being built to serve a single function on a proprietary platform, to deliver a single event or sequence the events from a single source to one service instance. Traditional platforms have associated a call or a sequence of events to a service instance and delivered all the events of that call or sequence to the same service instance. These special purpose platforms have worked well for stable services that support events from a single network. But special purpose platforms have proven cumbersome and expensive to modify and difficult for a support staff to integrate and maintain.
Services include two important components—service logic and service data. Service data may have both service scope data, which is the data that is common across the service, and subscriber scope data, which the data specific to a subscriber related to the service. A service execution environment like a SLEE benefits from support for persisting the data, provisioning the data, and exposing the data to services during runtime. Existing proprietary platforms support the service data by typically defining it using some method specific to the underlying database system of the platform—a proprietary language or a more generic language like SQL. Service developers typically also have to develop interfaces to provision this data along with the services. During execution, the services access the data using some proprietary programming interface or a more generic interface like JDBC. The problems with these platforms are multifold, including lack of compliance with JAIN SLEE or any similar telecommunications computing standard. First, the service developers need to understand the platform design to be able to develop data provisioning interfaces and have to manage their own data persistence by accessing and updating it using some programming interface. Second, the service data definition on proprietary platforms is so closely tied to the platform data that the platform has to restrict the power/functionality of service data definition, or require it to be statically defined before platform installation, so the proper analysis of its impact on the platform and other service on the platform can be done. This makes it hard to dynamically deploy a new service. Third, the service developers have to concern themselves with the underlying details of the platform database and user interfaces rather than just focusing on what the service does.
Services are typically triggered by events, requests or messages (we shall use the terms event and event notification to refer to all of them) originating in the call processing system and other external systems, and some of the service execution platform provided services as well. Addresses are the identifiers that typically identify the subscribers associated with the events by points of call origination, destination or both. Addresses also may identify participants in a service other than the subscriber.
With the development and improved capabilities of wireless communications and the Internet, more and more services are being offered on multiple networks. For example, a simple voice service could serve subscribers whose calls originate from a land based telephone network, a wireless telephone network, and an the Internet connection. Similarly, a text-based chat room could serve subscribers calling in from a public telephone, using a web browser over the internet, sending/receiving Short Messages from a wireless phone, and sending/receiving email from a distribution list. Enhanced services for subscribers from multiple networks are so-called converged services.
Accordingly, there is an opportunity to provide software components compliant with a telecommunications computing standard for a service logic execution environment, such as the emerging JAIN SLEE standard or a subsequent standard. In this new environment designed to support multiple types of service and multiple vendors, many components need to be developed to support development and execution of new services. For instance, there is an opportunity to provide methods and devices that assist service developers in specifying their service definition and requirements for the service data. In addition, it is useful to support services with component operable in the service logic execution environment that support data persistence and access, with minimal development effort by service developer.